Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow support channel settings to be either channel name OR channel ID #613

Merged
merged 4 commits into from
Oct 17, 2024

Conversation

rebkwok
Copy link
Contributor

@rebkwok rebkwok commented Oct 10, 2024

The bennett admins channel name was recently changed, which required a change to the production environment variable, because our settings used channel names and not channel ids. There are benefits to being able to use both.

Most slack functions will accept either a channel name or a channel ID. We always use a channel ID for support channels for the few functions that require it. For readability, our settings have used channel names, but the disadvantage is that if a channel name changes, bennettbot will no longer be able to post to it.

This allows settings to be either channel name or channel ID. If we decide to change them to channel IDs in prod, this means channel names can be changed with no interruption to how the support keywords work.

Most of the changes in this PR are actually just some refactoring of how the support channel config is set up.

This gets rid of some duplicate code and makes it simpler to add
additional support channels in future.
Most slack functions will accept either a channel name or a channel
ID. We always use a channel ID for support channels for the few that
require it. For readability, our settings have used channel names, but the
disadvantage is that if a channel name changes, bennettbot will no
longer be able to post to it.

This allows settings to be either channel name or channel ID. If we
decide to change them to channel IDs in prod, this means channel names
can be changed with no interruption to how the support keywords work.
@rebkwok rebkwok changed the title Support channelsAllow support channel settings to be either channel name OR channel ID Allow support channel settings to be either channel name OR channel ID Oct 10, 2024
@@ -290,7 +317,6 @@ def repost_support_request_to_channel(event, say, ack, keyword, channel_id):
# an exception; if this happens, then the user is editing something
# other than the keyword in the message, and we don't need to repost
# it again. We let the default error handler will deal with it.
reaction = {"tech-support": "sos", "bennett-admins": "flamingo"}[keyword]
Copy link
Contributor

@alarthast alarthast Oct 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reactions_add takes the emoji names without being wrapped by colons, so the new support_config should store them without the colons (lines 122 and 138)

Currently Slack will complain about not being able to add a reaction:
Unexpected error: SlackApiError("The request to the Slack API failed. (url: https://slack.com/api/reactions.add)\nThe server responded with: {'ok': False, 'error': 'invalid_name'}") while responding to message Add the reaction tech-support

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks! Although I feel sure that I tested this...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hah. No, I tested the bad job, which just reposts to tech-support

Comment on lines 114 to 118
# Get the channel ID by channel name. If it doesn't exist, assume the setting is
# already the channel ID
"channel_id": channels.get(
settings.SLACK_TECH_SUPPORT_CHANNEL, settings.SLACK_TECH_SUPPORT_CHANNEL
),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would this affect the message query in check_messages in MessageChecker, if the setting is already the channel ID? (Line 259, dispatcher.py)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MessageChecker is fine, it can take either the channel name or the ID

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although really, bot and dispatcher should share the same support config. I'll have a look at doing that as well as fixing the emoji

Both the bot and the message checker in the dispatcher use elements
of the support config, so move it out into a shared module.

I'm not greatly happy about having a config.py that this lives in,
but I don't want to pollute settings.py with functions that build
config, and I don't want dispatcher.py to be dependent on bot.py

Also fixes a bug with the reaction emoji config, and uses
"support_channel" as the key in the support config to be more
explicit about which channel we're referring to in functions that
use this config.
Comment on lines 12 to 13
# available, otherwise we default to using the setting value (on the
# assumption that the setting value is the channel name).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I guess if we do switch to using channel IDs in the settings, we will have to update this comment in that PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No - although I think I haven't said it very clearly, and I think I actually meant we assume the setting value is already the channel ID (not name). Currently the setting can be either the name or the ID; we first assume the setting is a channel name, and use it to retrieve the ID from the channels if the channels dict is available.
In the bot case, if if it can't be retrieved, we assume it's the ID already, and code in the handler registration checks that the IDs are valid.
In the dispatcher case, we don't have the dict of channel names to IDs available, so we default to using whatever the setting is, which may be a name or an ID.

I'll reword this comment

@rebkwok rebkwok merged commit 14d3421 into main Oct 17, 2024
6 checks passed
@rebkwok rebkwok deleted the support-channels branch October 17, 2024 11:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants